Zvládnutí komunikace mezi aplikacemi: Frontendová micro-frontend event bus

V oblasti moderního webového vývoje se micro-frontendy staly silným architektonickým vzorem. Umožňují týmům vytvářet a nasazovat nezávislé části uživatelského rozhraní, čímž podporují agilitu, škálovatelnost a autonomii týmu. Kritická výzva však nastává, když tyto nezávislé aplikace potřebují vzájemně komunikovat. Bez robustního mechanismu se micro-frontendy mohou stát izolovanými ostrovy, což brání soudržnému uživatelskému zážitku, který uživatelé očekávají. Právě zde vstupuje do hry frontendová micro-frontend event bus, která slouží jako centrální nervový systém pro komunikaci mezi aplikacemi.

Porozumění světu micro-frontendů

Než se ponoříme do event bus, krátce si připomeňme kontext micro-frontendů. Představte si velkou e-commerce platformu. Místo jedné monolitické frontendové aplikace bychom mohli mít:

• Micro-frontend produktového katalogu: Zodpovědný za zobrazení seznamů produktů, vyhledávání a filtrování.
• Micro-frontend nákupního košíku: Spravuje položky přidané do košíku, jejich množství a zahájení platby.
• Micro-frontend uživatelského profilu: Stará se o autentizaci uživatele, historii objednávek a osobní údaje.
• Micro-frontend doporučovacího systému: Navrhuje související produkty na základě chování uživatele.

Každý z nich může být vyvíjen, nasazován a udržován nezávisle různými týmy. To nabízí významné výhody:

• Technologická rozmanitost: Týmy si mohou vybrat nejlepší technologický stack pro svůj specifický micro-frontend.
• Autonomie týmu: Vývojové týmy mohou pracovat nezávisle bez rozsáhlé koordinace.
• Rychlejší cykly nasazení: Menší, nezávislá nasazení snižují riziko a zvyšují rychlost.
• Škálovatelnost: Jednotlivé micro-frontendy lze škálovat podle poptávky.

Výzva: Komunikace mezi aplikacemi

Krása nezávislého vývoje s sebou přináší významnou výzvu: jak spolu tyto oddělené aplikace komunikují? Zvažte tyto běžné scénáře:

• Když uživatel přidá položku do nákupního košíku, produktový katalog může potřebovat vizuálně naznačit, že položka je nyní v košíku (např. fajfkou).
• Když se uživatel přihlásí prostřednictvím micro-frontendu uživatelského profilu, ostatní micro-frontendy (jako doporučovací systém) mohou potřebovat znát stav autentizace uživatele pro personalizaci obsahu.
• Když uživatel provede nákup, nákupní košík může potřebovat informovat produktový katalog o aktualizaci stavu zásob nebo uživatelský profil o nové historii objednávek.

Přímá komunikace mezi micro-frontendy se často nedoporučuje, protože vytváří těsné vazby (tight coupling), což popírá mnohé z výhod architektury micro-frontendů. Potřebujeme volně vázaný, flexibilní a škálovatelný způsob, jak mohou interagovat.

Představení frontendové micro-frontend event bus

Event bus, také známá jako message bus nebo pub/sub (publish-subscribe) systém, je návrhový vzor, který umožňuje oddělenou komunikaci mezi různými částmi aplikace. V kontextu micro-frontendů funguje jako centrální uzel, kde mohou aplikace publikovat události a jiné aplikace se k těmto událostem mohou přihlásit k odběru.

Základní myšlenka je jednoduchá:

• Publisher (Vydavatel): Aplikace, která generuje událost a vysílá ji do sběrnice (bus).
• Subscriber (Odběratel): Aplikace, která naslouchá specifickým událostem na sběrnici a reaguje, když nastanou.
• Event Bus (Sběrnice událostí): Prostředník, který zprostředkovává doručení publikovaných událostí všem zainteresovaným odběratelům.

Tento vzor je také úzce spjat s návrhovým vzorem Observer (Pozorovatel), kde jeden objekt (subjekt) udržuje seznam svých závislých (pozorovatelů) a automaticky je informuje o jakýchkoli změnách stavu, obvykle voláním jedné z jejich metod.

Klíčové principy event bus pro micro-frontendy

1. Oddělení (Decoupling): Vydavatelé a odběratelé o sobě navzájem nemusí vědět. Interagují pouze prostřednictvím event bus.
2. Asynchronní komunikace: Události se obvykle zpracovávají asynchronně, což znamená, že vydavatel nemusí čekat, až odběratelé dokončí zpracování události.
3. Škálovatelnost: S přidáváním dalších micro-frontendů se mohou jednoduše přihlásit k odběru nebo publikovat události, aniž by ovlivnily ty stávající.
4. Centralizovaná logika (pro události): Zatímco aplikační logika zůstává distribuovaná, mechanismus zpracování událostí je centralizován prostřednictvím sběrnice.

Návrh vaší micro-frontend event bus

Existuje několik přístupů k implementaci micro-frontend event bus, každý s vlastními výhodami a nevýhodami. Volba často závisí na specifických potřebách vaší aplikace, použitých technologiích a strategii nasazení.

1. Globální Event Emitter (JavaScript)

Toto je běžný a relativně přímočarý přístup pro micro-frontendy nasazené ve stejném kontextu prohlížeče (např. pomocí module federation nebo komunikace přes iframe). Jeden sdílený objekt JavaScriptu funguje jako event bus.

Příklad implementace (konceptuální JavaScript)

Můžeme vytvořit jednoduchou třídu pro emisi událostí:

            class EventBus {
  constructor() {
    this.listeners = {};
  }

  subscribe(event, callback) {
    if (!this.listeners[event]) {
      this.listeners[event] = [];
    }
    this.listeners[event].push(callback);
    return () => {
      this.unsubscribe(event, callback);
    };
  }

  unsubscribe(event, callback) {
    if (!this.listeners[event]) {
      return;
    }
    this.listeners[event] = this.listeners[event].filter(listener => listener !== callback);
  }

  publish(event, data) {
    if (!this.listeners[event]) {
      return;
    }
    this.listeners[event].forEach(callback => {
      try {
        callback(data);
      } catch (error) {
        console.error(`Error in event handler for ${event}:`, error);
      }
    });
  }
}

// In your main application shell or a shared utility file:
export const sharedEventBus = new EventBus();

            

              
                Copy
              
            
          

Jak to micro-frontendy používají

Micro-frontend produktového katalogu (Vydavatel):

            import { sharedEventBus } from './sharedEventBus'; // Assuming sharedEventBus is imported correctly

function handleAddToCartButtonClick(productId) {
  // ... logic to add item to cart ...
  sharedEventBus.publish('itemAddedToCart', { productId: productId, quantity: 1 });
}

            

              
                Copy
              
            
          

Micro-frontend nákupního košíku (Odběratel):

            import { sharedEventBus } from './sharedEventBus'; // Assuming sharedEventBus is imported correctly

// When the cart component mounts or initializes
const subscription = sharedEventBus.subscribe('itemAddedToCart', (eventData) => {
  console.log('Item added to cart:', eventData);
  // Update cart UI, add item to internal state, etc.
  updateCartUI(eventData.productId, eventData.quantity);
});

// Remember to unsubscribe when the component unmounts to prevent memory leaks
// componentWillUnmount() { subscription(); }

            

              
                Copy
              
            
          

Co zvážit u globálních Event Emitterů

• Rozsah (Scope): Tento přístup funguje dobře, když jsou micro-frontendy načteny ve stejném okně prohlížeče a sdílejí globální rozsah nebo společný modulový systém (jako je Webpack Module Federation).
• Úniky paměti (Memory Leaks): Je klíčové implementovat správné mechanismy pro odhlášení odběru (unsubscription), když jsou komponenty micro-frontendu odpojeny (unmounted), aby se předešlo únikům paměti.
• Konvence pro pojmenování událostí: Stanovte jasné konvence pro pojmenování událostí, abyste předešli kolizím a zajistili udržovatelnost. Například použijte prefix jako [nazev-micro-frontendu]:nazevUdalosti.
• Struktura dat: Definujte konzistentní datové struktury pro události.

2. Vlastní události (Custom Events) a DOM Dispatching

Další nativní přístup v prohlížeči využívá DOM jako komunikační kanál. Micro-frontendy mohou odesílat vlastní události na sdíleném prvku DOM (např. objektu `window` nebo určeném kontejnerovém prvku) a ostatní micro-frontendy mohou těmto událostem naslouchat.

Příklad implementace (konceptuální JavaScript)

Micro-frontend produktového katalogu (Vydavatel):

            
function handleAddToCartButtonClick(productId) {
  const event = new CustomEvent('microfrontend:itemAddedToCart', {
    detail: { productId: productId, quantity: 1 }
  });
  window.dispatchEvent(event);
}

            

              
                Copy
              
            
          

Micro-frontend nákupního košíku (Odběratel):

            
const handleItemAdded = (event) => {
  console.log('Item added to cart:', event.detail);
  updateCartUI(event.detail.productId, event.detail.quantity);
};

window.addEventListener('microfrontend:itemAddedToCart', handleItemAdded);

// Remember to remove the listener when the component unmounts
// window.removeEventListener('microfrontend:itemAddedToCart', handleItemAdded);

            

              
                Copy
              
            
          

Co zvážit u vlastních událostí (Custom Events)

• Kompatibilita prohlížečů: `CustomEvent` je široce podporován, ale vždy je dobré si to ověřit.
• Limity přenosu dat: Vlastnost `detail` objektu `CustomEvent` může přenášet libovolná serializovatelná data.
• Znečištění globálního jmenného prostoru: Odesílání událostí na objektu `window` může vést ke kolizím názvů, pokud není spravováno opatrně.
• Výkon: Pro velmi vysoký objem událostí to nemusí být nejvýkonnější řešení ve srovnání s dedikovaným event emitterem.

3. Fronty zpráv nebo externí brokeři (pro složitější scénáře)

Pro micro-frontendy, které mohou běžet v různých kontextech prohlížeče (např. iframy z různých původů), nebo pokud potřebujete robustnější funkce jako zaručené doručení, perzistenci zpráv nebo vysílání na serverové komponenty, můžete zvážit použití externích systémů front zpráv.

Příklady zahrnují:

• WebSockets: Pro obousměrnou komunikaci v reálném čase.
• Server-Sent Events (SSE): Pro jednosměrnou komunikaci ze serveru na klienta.
• Dedikovaní message brokeři: Jako RabbitMQ, Apache Kafka nebo cloudová řešení (AWS SQS/SNS, Google Cloud Pub/Sub).

Příklad implementace (konceptuální - WebSockets)

Backendový WebSocket server funguje jako centrální broker.

Micro-frontend produktového katalogu (Vydavatel):

            
// Assuming a WebSocket connection is established and managed globally
function handleAddToCartButtonClick(productId) {
  if (websocketConnection.readyState === WebSocket.OPEN) {
    websocketConnection.send(JSON.stringify({
      event: 'itemAddedToCart',
      data: { productId: productId, quantity: 1 }
    }));
  }
}

            

              
                Copy
              
            
          

Micro-frontend nákupního košíku (Odběratel):

            
// Assuming a WebSocket connection is established and managed globally
websocketConnection.onmessage = (event) => {
  const message = JSON.parse(event.data);
  if (message.event === 'itemAddedToCart') {
    console.log('Item added to cart (from WS):', message.data);
    updateCartUI(message.data.productId, message.data.quantity);
  }
};

            

              
                Copy
              
            
          

Co zvážit u externích brokerů

• Náklady na infrastrukturu: Vyžaduje nastavení a správu samostatné služby.
• Latence: Komunikace obvykle prochází serverem, což může způsobit latenci.
• Složitost: Složitější na nastavení a správu než řešení v prohlížeči.
• Škálovatelnost a spolehlivost: Často nabízí vyšší záruky škálovatelnosti a spolehlivosti.
• Komunikace mezi různými původy (Cross-Origin): Nezbytné pro iframy z různých původů.

Osvědčené postupy pro implementaci micro-frontend event bus

Bez ohledu na zvolenou implementaci, dodržování osvědčených postupů zajistí robustní a udržovatelný systém.

1. Definujte jasný kontrakt pro události

Každá událost by měla mít dobře definovanou strukturu. To zahrnuje:

• Název události: Jedinečný a popisný identifikátor.
• Struktura datového obsahu (Payload): Tvar a typy dat, které událost nese.

Příklad:

Název události: userProfile:authenticated

Datový obsah (Payload):

            {
  "userId": "abc-123",
  "timestamp": "2023-10-27T10:30:00Z"
}

            

              
                Copy
              
            
          

2. Stanovte konvence pro pojmenování

Abyste se vyhnuli konfliktům v názvech, zejména ve větších architekturách micro-frontendů, implementujte konzistentní strategii pojmenování. Důrazně se doporučují prefixy.

• Prefixy založené na rozsahu: [nazev-microfrontendu]:[nazevUdalosti] (např. katalog:produktZobrazen, kosik:polozkaOdstranena)
• Prefixy založené na doméně: [domena]:[nazevUdalosti] (např. auth:uzivatelPrihlasen, objednavky:objednavkaZadana)

3. Zajistěte správné odhlášení odběru

Úniky paměti jsou běžnou pastí. Vždy se ujistěte, že posluchače jsou odstraněny, když komponenta nebo micro-frontend, který je zaregistroval, již není aktivní. To je obzvláště důležité v jednostránkových aplikacích (SPA), kde jsou komponenty dynamicky vytvářeny a ničeny.

            // Example using a framework like React
import React, { useEffect } from 'react';
import { sharedEventBus } from './sharedEventBus';

function OrderSummary({ orderId }) {
  useEffect(() => {
    const subscription = sharedEventBus.subscribe('order:statusUpdated', (data) => {
      if (data.orderId === orderId) {
        console.log('Order status updated:', data.status);
        // Update component state based on new status
      }
    });

    // Cleanup function: unsubscribe when the component unmounts
    return () => {
      subscription(); // This calls the unsubscribe function returned by subscribe
    };
  }, [orderId]); // Re-subscribe if orderId changes

  return (
    

      
Order #{orderId}
      {/* ... order details ... */}
    
  );
}

            

              
                Copy
              
            
          

4. Zpracovávejte chyby elegantně

Co se stane, když odběratel vyvolá chybu? Implementace event bus by v ideálním případě neměla zastavit zpracování ostatních odběratelů. Implementujte bloky `try...catch` kolem volání callbacků, abyste zajistili odolnost.

5. Zvažte granularitu událostí

Vyhněte se vytváření příliš obecných událostí, které vysílají příliš mnoho dat nebo příliš často. Naopak, nevytvářejte události, které jsou příliš specifické a vedou k explozi typů událostí.

• Příliš obecné: Událost jako dataChanged je neužitečná.
• Příliš specifické: productNameChanged, productPriceChanged, productDescriptionChanged by mohly být lépe rozděleny do jedné události product:updated se specifickými poli označujícími, co se změnilo, nebo zpracovány aplikací, která data vlastní.

Snažte se o rovnováhu, která reprezentuje smysluplné změny stavu nebo akce ve vašem systému.

6. Správa verzí událostí (Versioning)

Jak se vaše architektura micro-frontendů vyvíjí, struktury událostí se mohou měnit. Zvažte strategii správy verzí pro vaše události, zejména pokud používáte externí message brokery nebo pokud výpadek při aktualizacích není možný.

7. Globální event bus jako sdílená závislost

Pokud používáte sdílený JavaScript event emitter, ujistěte se, že je skutečně sdílen napříč všemi vašimi micro-frontendy. Technologie jako Webpack Module Federation to usnadňují tím, že vám umožňují globálně vystavovat a spotřebovávat moduly.

            // webpack.config.js (in host application)
module.exports = {
  //...
  plugins: [
    new ModuleFederationPlugin({
      name: 'hostApp',
      remotes: {
        catalogApp: 'catalogApp@http://localhost:3001/remoteEntry.js',
        cartApp: 'cartApp@http://localhost:3002/remoteEntry.js',
      },
      shared: {
        './src/sharedEventBus': { 
          singleton: true, 
          eager: true // Load immediately
        }
      }
    })
  ]
};

// webpack.config.js (in micro-frontend 'catalogApp')
module.exports = {
  //...
  plugins: [
    new ModuleFederationPlugin({
      name: 'catalogApp',
      filename: 'remoteEntry.js',
      exposes: {
        './CatalogApp': './src/bootstrap',
        './SharedEventBus': './src/sharedEventBus'
      },
      shared: {
        './src/sharedEventBus': {
          singleton: true,
          eager: true
        }
      }
    })
  ]
};

            

              
                Copy
              
            
          

Kdy nepoužívat event bus

Ačkoli je event bus mocný nástroj, není to univerzální řešení pro všechny komunikační potřeby. Nejlépe se hodí pro vysílání událostí a zpracování vedlejších efektů. Obecně to není ideální vzor pro:

• Přímý požadavek/odpověď (Request/Response): Pokud micro-frontend A potřebuje specifická data z micro-frontendu B a musí na tato data okamžitě čekat, přímé volání API nebo řešení pro správu sdíleného stavu může být vhodnější než vyslání události a doufání v odpověď.
• Složitá správa stavu: Pro správu složitého sdíleného stavu aplikace napříč více micro-frontendy může být vhodnější dedikovaná knihovna pro správu stavu (potenciálně s vlastním modelem událostí nebo odběrů).
• Kritické synchronní operace: Pokud je vyžadována okamžitá, synchronní koordinace, asynchronní povaha event bus může být nevýhodou.

Alternativní komunikační vzory v micro-frontech

Je třeba poznamenat, že event bus je jen jedním z nástrojů v sadě pro komunikaci mezi micro-frontendy. Mezi další vzory patří:

• Sdílená správa stavu: Knihovny jako Redux, Vuex nebo Zustand mohou být sdíleny mezi micro-frontendy pro správu společného stavu.
• Props a Callbacks: Když je jeden micro-frontend přímo vložen nebo složen v jiném (např. pomocí Webpack Module Federation), lze použít přímé předávání props a callbacků, i když to zavádí těsnější vazbu.
• Web Components/Custom Elements: Mohou zapouzdřit funkcionalitu a vystavit vlastní události a vlastnosti pro komunikaci.
• Směrování (Routing) a parametry URL: Sdílení stavu prostřednictvím URL může být jednoduchý a bezstavový způsob komunikace.

Často se pro vytvoření komplexní architektury micro-frontendů používá kombinace těchto vzorů.

Globální příklady a úvahy

Při budování micro-frontend event bus pro globální publikum zvažte tyto body:

• Časová pásma: Ujistěte se, že všechna časová razítka v událostech jsou v univerzálně srozumitelném formátu (jako ISO 8601 s UTC) a že spotřebitelé vědí, jak je interpretovat.
• Lokalizace/Internacionalizace (i18n): Samotné události obvykle nenesou text pro UI, ale pokud spouštějí aktualizace UI, tyto aktualizace musí být lokalizovány. Data událostí by měla být ideálně jazykově nezávislá.
• Měna a jednotky: Pokud události zahrnují peněžní hodnoty nebo měření, buďte explicitní ohledně měny nebo jednotky, nebo navrhněte datový obsah tak, aby je zohledňoval.
• Regionální předpisy (např. GDPR, CCPA): Pokud události přenášejí osobní údaje, ujistěte se, že implementace event bus a zúčastněné micro-frontendy splňují příslušné předpisy o ochraně osobních údajů. Zajistěte, aby data byla publikována pouze odběratelům, kteří je legitimně potřebují a mají zavedeny vhodné mechanismy souhlasu.
• Výkon a šířka pásma: Pro uživatele v regionech s pomalejším internetovým připojením se vyhněte příliš "upovídaným" vzorům událostí nebo velkým datovým obsahům. Optimalizujte přenos dat.

Závěr

Frontendová micro-frontend event bus je nepostradatelným vzorem pro umožnění bezproblémové, oddělené komunikace mezi nezávislými micro-frontend aplikacemi. Přijetím modelu publish-subscribe mohou vývojové týmy vytvářet složité, škálovatelné webové aplikace a zároveň si zachovat agilitu a autonomii.

Ať už se rozhodnete pro jednoduchý globální event emitter, využijete vlastní události DOM, nebo se integrujete s robustními externími message brokery, klíč spočívá v definování jasných kontraktů, stanovení konzistentních konvencí a pečlivé správě životního cyklu vašich posluchačů událostí. Dobře implementovaná event bus promění vaše micro-frontendy z izolovaných komponent na soudržný, dynamický a responzivní uživatelský zážitek.

Při navrhování vaší další micro-frontendové iniciativy nezapomeňte upřednostnit komunikační strategie, které podporují volné vazby a škálovatelnost. Event bus, pokud je používána promyšleně, bude základním kamenem vašeho úspěchu.